Celestin Apprentice 5/Apprentice-Release5.iso/Information/CSMP Digest/volume 3/csmp-digest-v3-055

Text File | 1995-12-31 | 82KB | 2,076 lines

Received-Date: Thu, 8 Sep 1994 18:50:22 +0200
From: [e-mail] (Francois Pottier)
Subject: csmp-digest-v3-055
To: [e-mail]
Date: Thu, 8 Sep 1994 18:50:13 +0200 (MET DST)
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Errors-To: [e-mail]
Reply-To: [e-mail]
X-Sequence: 60

C.S.M.P. Digest             Thu, 08 Sep 94       Volume 3 : Issue 55

Today's Topics:

        Clover+. interrupt?~
        Standard C Libraries: use them?
        Summary of 'Safe Save' problem - IM:Files flawed!
        What Happens in the Resource Fork
        Why does NewGWorld do this?
        Won't strange windows come in my layer?



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, you may
still be able to post messages to the group by using a mail server like
anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                        Sends you a summary of commands
    subscribe csmp-digest Your Name    Adds you to the mailing list
    signoff csmp-digest            Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail]. Currently no previous volumes of the CSMP
digest are available there.

Also, the digests are available to WAIS users.  To search back issues
with WAIS, use comp.sys.mac.programmer.src. With Mosaic, use
http://www.wais.com/wais-dbs/comp.sys.mac.programmer.html.


-------------------------------------------------------

>From [e-mail] (Arthur Babitz)
Subject: Clover+. interrupt?
Date: Tue, 23 Aug 1994 13:51:08 -0800
Organization: Mentor Graphics Corp., Wilsonville, OR., USA

I've been trying unsuccessfully to implement a "clover+." interrupt for a
compute intensive part of an application.  I won't bore you with a list of
things I've tried which don't work, but can someone point me in the right
direction?  Seems like there must be a standard, simple solution to this
problem.

Thanks!

+++++++++++++++++++++++++++

>From [e-mail] (Timothy Sherburne)
Date: 24 Aug 94 16:19:46 GMT
Organization: University of Portland

[e-mail] (Arthur Babitz) writes:

>I've been trying unsuccessfully to implement a "clover+." interrupt for a
>compute intensive part of an application.  I won't bore you with a list of
>things I've tried which don't work, but can someone point me in the right
>direction?  Seems like there must be a standard, simple solution to this
>problem.

>Thanks!

The trick is to check for a cmd-. (the "clover" key is usually called the command key) in your event loop.  Or you could implement a GetKeys filter.

Here's a snippet using WaitNextEvent that returns a "true" if cmd-. is detected:

Boolean CheckForCmdPeriod (void)
{
    EventRecord    theEvent;
    char        key;
    Boolean        result = false;

    // Wait for an event...

    if (WaitNextEvent (keyDownMask, &theEvent, kMaxSleep, nil))
    {
        // Get the ASCII value of the key from the event record...

        key = theEvent.message & charCodeMask;

        // If the key value is equal to that of the period key and
        // the command modifier key is also being held down, then
        // set result to true...

        if ((theEvent.modifiers & cmdKey) && key == '.')   // cmd-.
            result = true;
    }

    return result;
}

Here's a snippet using the "GetKeys" toolbox call:

Boolean CheckForCmdPeriod (void)
{
    KeyMap        keys;

    // Check to see if the user has pressed command-period keys...

    GetKeys (keys);
    if(keys [1] & 0x00800000)    // command
    {
        GetKeys (keys);
        if(keys[1] & 0x00008000)    // . (period)
        {
            FlushEvents (mDownMask + mUpMask, 0);
            return true;
        }
    }
    else
        return false;
}

The GetKeys call will catch cmd-. that is intended for anyone, so use it sparingly.  It will also not filter the cmd-.



Don't Panic,


t
--
  | Timothy Sherburne                    |               Software Engineer |
  | Internet:  [e-mail]      |       Prometheus Products, Inc. |
  | AppleLink: [e-mail] |                  1-800-477-3473 |
*All comments are my own and in no way represent those of Prometheus Products*

+++++++++++++++++++++++++++

>From [e-mail] (David Shayer)
Date: Wed, 24 Aug 1994 18:04:50 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

Arthur Babitz ([e-mail]) wrote:
: I've been trying unsuccessfully to implement a "clover+." interrupt for a
: compute intensive part of an application.  I won't bore you with a list of
: things I've tried which don't work, but can someone point me in the right
: direction?  Seems like there must be a standard, simple solution to this
: problem.

The simplest solution is to simply call WaitNextEvent every so often,
checking for keydown events of cmd-period.  This is polling, not
interrupt based.  But that's the correct way to do it on a Mac.

David


+++++++++++++++++++++++++++

>From [e-mail] (Ron Nicholson)
Date: Thu, 25 Aug 1994 02:02:12 GMT
Organization: Silicon Graphics, Inc., Mountain View, CA

In article <timothys.777745186@hood>,
Timothy Sherburne <[e-mail]> wrote:
>[e-mail] (Arthur Babitz) writes:
>
>>I've been trying unsuccessfully to implement a "clover+." interrupt for a
>>compute intensive part of an application.  I won't bore you with a list of
>>things I've tried which don't work, but can someone point me in the right
>>direction?  Seems like there must be a standard, simple solution to this
>>problem.
(snip)
>Here's a snippet using WaitNextEvent that returns a "true" if cmd-. ...
>
(snip)

A program has to call WaitNextEvent to cleanly check for a keyboard
abort (command-period).  I tried this in an inner loop of a compute
intensive application and it slowed down the computation noticeably.
I had to figure out a way to poll often enough to not make the user
interface seem sluggish, while slowing calculation down minimally.

What I now do is to is this:

First I install a VBL task whose only function is to increment a global
variable.  That gives me a tickcount variable that can be read without
a function call.  You can also use the TickCount() access function.
(Or you can just use the lowmem global Ticks at $016A if you aren't
strictly following Apple's guidelines.  Would I do that? :-)

In my inner loop I have code similar to:    /* in pseudo code */

int ComputeIntensiveFunction(parameters ...)
{
  ...
  volatile long int    *myTickCountPtr;
  long int        CheckNow;
  int            LocalCounter;        /* a local variable */

  myTickCountPtr = &some_tickcount_global;     /* point at tickcount */
  CheckNow = *myTickCountPtr + 6;        /* every 10th of a second */
  LocalCounter = 25;
  ...

  for (i=1,i<1000000000;i++) {

    ...  /* compute intensive inner loop stuff that goes on forever */

    if (--LocalCounter <= 0) {
      if (*myTickCountPtr >= CheckNow) {
    flag = CheckForAbortEvent();    /* wrapper for WaitNextEvent */
    if (flag)
        return(kSomeErrorCode);    /* abort calculation    */
                    /* or alternatively just break */
    else
      CheckNow = *myTickCountPtr + 6;
      }
      LocalCounter = 25;        /* or some such value    */
    }
  }
  ...
  return(kFinishedCalculating);
}

Every time through the loop, the code does one local variable decrement
and compare.  Every 25th time, the code does one global variable
(probably uncached and thus slower) load and compare.  Every 10th of a
second, the code polls the event queue for abort, application switches, etc.

The "6" and "25" are just example values.  You might want to choose the
initial loop counter value based on application tuning and the processor
speed of the Mac on which the application is running.

- -
Ronald H. Nicholson, Jr.    [e-mail], [e-mail], N6YWU
#include <canonical.disclaimer>     // I speak only for myself, etc.

+++++++++++++++++++++++++++

>From [e-mail] (RadixInc)
Date: 25 Aug 1994 01:11:10 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <[e-mail]>, [e-mail] (Ron
Nicholson) writes:

<<
A program has to call WaitNextEvent to cleanly check for a keyboard
abort (command-period).  I tried this in an inner loop of a compute
intensive application and it slowed down the computation noticeably.
I had to figure out a way to poll often enough to not make the user
interface seem sluggish, while slowing calculation down minimally.
>>

A program has to call WaitNextEvent to cleanly do a lot of things. If you
aren't checking events you are hogging the machine and not letting other
apps have time. And what do you mean "not make the user interface seem
sluggish?" What user interface do you have when you aren't checking for
events?

<<
First I install a VBL task whose only function is to increment a global
variable.  That gives me a tickcount variable that can be read without
a function call.  You can also use the TickCount() access function.
(Or you can just use the lowmem global Ticks at $016A if you aren't
strictly following Apple's guidelines.  Would I do that? :-)
>>

This is silly. Just call TickCount(), or if you have to, just look at
Ticks. You are overly worried about performance, yet you install a VBL
task that does the same thing as an existing VBL task (how do you think
Ticks gets updated in the first place?). You can use any DOCUMENTED
low-memory globals, like Ticks, without getting in trouble. Certainly
given the choice between that and installing a VBL, DTS would advise the
former.

As for the code sample, why not call EventAvail periodically with an event
mask that ignores events you don't care about? That way you won't end up
with an event loop inside your compute-intensive loop and (presumably)
another one in your main program. (DTS will certainly frown on calling
WaitNextEvent from more than one place in your program). And rather than
using Ticks and the local counter, use a modulo calculation on your loop
variable; e.g. check for an event every 10,000 iterations or so.

Make it work first, optimize the slow parts later [after identifying the
slow parts].

Gregory Jorgensen
Radix Consulting Inc.

+++++++++++++++++++++++++++

>From [e-mail] (Ron Nicholson)
Date: Thu, 25 Aug 1994 17:31:16 GMT
Organization: Silicon Graphics, Inc., Mountain View, CA

In article <33h95e$[e-mail]>,
RadixInc <[e-mail]> wrote:
>
>As for the code sample, why not call EventAvail periodically with an event
>mask that ignores events you don't care about? That way you won't end up
>with an event loop inside your compute-intensive loop and (presumably)
>another one in your main program. (DTS will certainly frown on calling
>WaitNextEvent from more than one place in your program). And rather than
>using Ticks and the local counter, use a modulo calculation on your loop
>variable; e.g. check for an event every 10,000 iterations or so.
>

You're right, EventAvail is a better choice for polling.  But what's
wrong with calling WNE from more than one place?  WNE has an eventmask
also.  I just get the events that I want to abort my loop, allow WNE to
put the program in the background, etc.

Using a modula on the loop count is very bad.  The difference in speed
between a Plus and a 8100/80 is enormous, especially on FP stuff.
Either you will poll much to seldom on slow machines.  Or waste a lot
of time in WNE on fast machines.  That's assuming that the time through
the loop is deterministic.  If it isn't, the Mac GUI could get jerky
suddenly if the modulo is set wrong on any machine.

My goal was to poll WNE at the same rate on slow and fast machines so
that the Mac GUI never feels jerky (menus drop promptly, etc.).  Around
the neighborhood of 15 times a second feels about right.  This works
for me and doesn't slow down a program that spends a lot of time doing
FFT's more than 1%.

- -
Ronald H. Nicholson, Jr.    [e-mail], [e-mail], N6YWU
#include <canonical.disclaimer>     // I speak only for myself, etc.

+++++++++++++++++++++++++++

>From [e-mail] (RadixInc)
Date: 25 Aug 1994 15:29:10 -0400
Organization: America Online, Inc. (1-800-827-6364)

I understand that the overhead of making the WNE toolbox call and polling
for events is time consuming, especially if you are trying to squeeze the
most performance out of a loop. Lots of programs just put up the "watch"
cursor and ignore all events while they do their computation. This is
considered bad etiquette, because WNE does more than just feed events to
your app. It is the only way to let other processes have time. Those other
processes may just be apps sitting there waiting for user input, in which
case it doesn't matter, but they may be important background processes,
such as network software or background printing.

Because so many programs are rude about giving up time with WNE, some
developers have gone the route of installing VBL or Time Manager tasks to
make sure they get time, and this is even worse.

If your method of calling WNE every 10 ticks works, and you can live with
the potential problems of having two WNE calls in your program, great. I
still think you'd be better off calling EventAvail with an event mask, so
if an event does show up you can exit your loop and let your "main" even
loop handle the event (EventAvail doesn't dequeue the event). You can use
a mask to just look for keyboard events, so mouse events and so on are
ignored (but remain in the even queue).

Also keep in mind that, depending on the speed of the Mac you are running
on, events don't live all that long. The event queue only holds 20 events,
and if you aren't removing them with WNE the old events will be lost. That
means you have to poll for events fast enough to catch them before they
are lost. User-interface events will happen much less frequently than
every 10 ticks, but network events may happen very fast on certain Macs.


Gregory Jorgensen
Radix Consulting Inc.

+++++++++++++++++++++++++++

>From [e-mail] (Mark Wilkins)
Date: 25 Aug 1994 21:03:07 GMT
Organization: Harvey Mudd College, Claremont CA

In article <33ire6$[e-mail]>,
RadixInc <[e-mail]> wrote:
>If your method of calling WNE every 10 ticks works, and you can live with
>the potential problems of having two WNE calls in your program, great. I
>still think you'd be better off calling EventAvail with an event mask...


  What possible problems could be caused by having multiple calls to
WaitNextEvent in an application, especially if the purpose is to check for
interruption of a time-consuming process?

  An application which doesn't try to do nifty things like threading will
usually limit user input during a time-consuming processing task to that
which could interrupt the task or that which needs to be passed on to the OS
such as a click in another app's window.

  In other words, why should I care if I'm throwing away events which don't
consist of a command period or mouse click when those are the only two forms
of interaction my application will entertain when it's chugging away?  That
is, assuming I'm only throwing away events directed at my application...

  I'm just not sure I see the issue.

-- Mark Wilkins

+++++++++++++++++++++++++++

>From [e-mail] (RadixInc)
Date: 26 Aug 1994 00:11:08 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <33j0ub$[e-mail]>, [e-mail] (Mark
Wilkins) writes:

<<What possible problems could be caused by having multiple calls to
WaitNextEvent in an application, especially if the purpose is to check for
interruption of a time-consuming process? ... In other words, why should I
care if I'm throwing away events which don't consist of a command period
or mouse click when those are the only two forms of interaction my
application will entertain when it's chugging away?  That is, assuming I'm
only throwing away events directed at my application...>>

It's mostly a matter of style, and of course it is generic Mac programming
advice to have only one place in your code call WNE. It sounds like you
know what you are doing, and perhaps this is the best way to handle it.
The complication of calling WNE from more than one place is that you have
to (or at least should) handle ALL events you get. In your case you are
going to ignore all events except the ones that can terminate your loop.
It's most important that you call WNE periodically (and often), for the
reasons mentioned in my previous post, even if you don't handle all of the
events.

Besides the key and mouse events, there are other events you may get. You
can't really get switched out if you ignore mouse clicks outside of your
window, but another process could do something that causes an update event
in one of your windows. Or a high-level event could get passed to you (if
your program accepts them). If you call WNE but can't respond to these
events in your computation loop, your window won't be updated and you
won't be able to process Apple Events. In your case maybe this is not a
big deal.

There is no "hard" reason to have only one WNE call in your program, as
long as you know that you may lose events.

Gregory Jorgensen
Radix Consulting Inc.

+++++++++++++++++++++++++++

>From [e-mail] (Kluev)
Date: Sun, 28 Aug 94 18:13:09 +0400
Organization: (none)

In article <33h95e$[e-mail]>
[e-mail] (RadixInc) wrote:

> In article <[e-mail]>, [e-mail]
(Ron
> Nicholson) writes:
> <<
> First I install a VBL task whose only function is to increment a
global
> variable.  That gives me a tickcount variable that can be read
without
> a function call.  You can also use the TickCount() access function.
> (Or you can just use the lowmem global Ticks at $016A if you aren't
> strictly following Apple's guidelines.  Would I do that? :-)
> >>
> This is silly. Just call TickCount(), or if you have to, just look at
> Ticks. You are overly worried about performance, yet you install a
VBL
> task that does the same thing as an existing VBL task (how do you
think
> Ticks gets updated in the first place?).

First: There is no special VBL task that increments Ticks.
Second: Installing VBLTask that increments global variable gives you
much less accuracy than looking into Ticks (TickCount). This inaccuracy
will heavily depend on machine load and may rise up to several "real"
ticks against one "your" tick. Ticks is guaranteed to be incremented
every tick, but your VBLTask (which contains 1 in vblCount) is not
guaranteed to be called every tick.

> WaitNextEvent from more than one place in your program). And rather
than
> using Ticks and the local counter, use a modulo calculation on your
loop
> variable; e.g. check for an event every 10,000 iterations or so.

This is bad practice. If "10,000" is hard-coded you will get different
response time on different machines. It may be computed at start-time.
But think: machine load (VBLs for example) may vary during program
execution. Processor cache may be turned on/off. All this and more
will invalidate this "10,000" estimate. Ticks is better.

Michael Kluev.

+++++++++++++++++++++++++++

>From [e-mail] (RadixInc)
Date: 29 Aug 1994 02:13:04 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <[e-mail]>, [e-mail]
(Kluev) writes:

<<First: There is no special VBL task that increments Ticks.>>

Not on newer Macs, no. Ticks used to get updated by a VBL task, but now it
is synthesized. It doesn't matter how it gets updated; the point is that
it is better to get the value of Ticks, either by function call or reading
the global directly. If you use the Universal Headers you can read the
Ticks global and stay compatible by using LMGetTicks(). For historical
reasons it's easier to pretend that Ticks is incremented at VBL time, even
though on most Macs it isn't actually done that way. I apologize if anyone
was confused or misled by my statement, but it really makes no difference
how Ticks gets incremented, and by design it appears that it is done at
VBL time.

<<This is bad practice. If "10,000" is hard-coded you will get different
response time on different machines.>>

Obviously, but you are misreading my message. I wasn't suggesting
hard-coding the number 10,000, or any other number--I was suggesting a
modulo calculation based on SOME modulus. The actual number used could be
any value, and could be calculated in advance to account for differences
among machines. 10,000 was simply an illustrative example, and that's why
I wrote "e.g. check for an event every 10,000 iterations or so."  "e.g."
is an abbrevation for "exempli gratia," meaning "for example," not to be
confused with "i.e.," (id est), meaning "that is." This should be
self-evident to anyone capable of writing a VBL task in the first place,
and therefore I didn't see any reason to exhaustively explain what I was
suggesting. Quod erat demonstrandum.

<<But think: machine load (VBLs for example) may vary during program
execution. Processor cache may be turned on/off. All this and more
will invalidate this "10,000" estimate. Ticks is better.>>

I agree, but the original post, and my response, were discussing other
approaches. My suggestion, which was followed up by email, was to simply
read the value of Ticks and be done with it. Done correctly the modulus
method is a legitimate way to handle the problem, if for some reason the
programmer doesn't want to use Ticks.

Gregory Jorgensen
Radix Consulting Inc.

+++++++++++++++++++++++++++

>From [e-mail] (David Besbris)
Date: 29 Aug 1994 10:25:39 GMT
Organization: The Avant-Garde of the Now, Ltd.

Kluev ([e-mail]) wrote:
(snip)

: First: There is no special VBL task that increments Ticks.
: Second: Installing VBLTask that increments global variable gives you
: much less accuracy than looking into Ticks (TickCount). This inaccuracy
: will heavily depend on machine load and may rise up to several "real"
: ticks against one "your" tick. Ticks is guaranteed to be incremented
: every tick, but your VBLTask (which contains 1 in vblCount) is not
: guaranteed to be called every tick.

(snip)

: This is bad practice. If "10,000" is hard-coded you will get different
: response time on different machines. It may be computed at start-time.
: But think: machine load (VBLs for example) may vary during program
: execution. Processor cache may be turned on/off. All this and more
: will invalidate this "10,000" estimate. Ticks is better.

: Michael Kluev.

Ticks is INDEED incremented by a system-installed VBL task, and is NOT
guaranteed to be inceremented exactly  once evey tick. (for the reasons that
you mention about the inaccuracy of using a VBL task.) I'm curious, why do you
say otherwise?


-Dave

One of the last Mac Pascal programmers...

[e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Kluev)
Date: Tue, 30 Aug 94 16:42:18 +0400
Organization: (none)

In article <33sd33$[e-mail]>
[e-mail] (David Besbris) wrote:

> Kluev ([e-mail]) wrote:
> (snip)
>
> : First: There is no special VBL task that increments Ticks.
> : Second: Installing VBLTask that increments global variable gives
you
> : much less accuracy than looking into Ticks (TickCount). This
inaccuracy
> : will heavily depend on machine load and may rise up to several
"real"
> : ticks against one "your" tick. Ticks is guaranteed to be
incremented
> : every tick, but your VBLTask (which contains 1 in vblCount) is not
> : guaranteed to be called every tick.
>
> : Michael Kluev.
>
> Ticks is INDEED incremented by a system-installed VBL task, and is
NOT
> guaranteed to be inceremented exactly  once evey tick. (for the
reasons that
> you mention about the inaccuracy of using a VBL task.) I'm curious,
why do
> you say otherwise?
>
> -Dave

Here's the story on how VBL mechanism work, at least as I understand
it. Ticks is updated by "VBL mechanism", *not* by system-installed
VBL task. The first thing that is done by VBL mechanism is incrementing
Ticks variable. Then it gets sure that it is not already running
(by looking in VBLQueue). If it is already running, there is nothing
to do, just return. If it is not running, mechanism decrements
vblCounts of VBL tasks, and calls those, which have zero in vblCount.
While VBL task is getting called, VBL mechanism may be entered again.
(This is another story, how is it getting called: is it real video card
interrupt, or is it triggered VIA interrupt. For now it is important
only, that mechanism is getting called every 1/60 sec or so.) In this
case the only thing it does is incrementing Ticks variable. So Ticks
*is guaranteed* (if we aren't talking about situations when interrupts
are disabled for a long time, e. g. diskette formatting) to be
incremented every tick, but VBL task that has 1 in vblCount
*is not guaranteed* to be called every tick. As far as I know all
Macs since 1984 share this scheme.

If you don't believe me, disassemble a few bytes of ROM above the
code that calls your VBL task (on my machine it starts at
"_VRemove+16".
You will see:

+0014 RTS
; Starting point of "VBL mechanics"
+0016 ADDQ.L #$1, Ticks;     increments Ticks global
+001A .....
+0020 BSET #$06, VBLQueue;   test if it is already running
+0026 BNE _VRemove+0014;     nothing can do - return.

If you still don't believe me, write a small test. Install VBL task
that does the following:
  ...
  Task-> vblCount = 1;            // reinstalls itself
  MyTicks++;                      // increments global
  Delay(10, &L);                  // degrades machine performance,
                                  // (emulates Mac Plus or so)
// You may try to use this "for" loop instead of Delay
//  for (i = 0; i < 1000000L; i++);
  ...

In your main write:
   ...
   VInstall(...);            // installs VBL task with 1 in vblCount
   MyOldTicks = MyTicks;     // saves old timers
   OldTicks = TickCount();
   Delay(60*10);             // waits 10 seconds
   MyNewTicks = MyTicks;
   NewTicks = TickCount();   // gets new timers

   NumToString(MyNewTicks - MyOldTicks, String);
   DebugStr(String);
   NumToString(NewTicks - OldTicks, String);
   DebugStr(String);              // makes things obvious

...You will notice a big difference.

As someone else pointed, for more exact and/or long-term measurements
it is better to use other mechanisms instead of Ticks (e. g. Time
Manager or GetDateTime).

Michael Kluev.

+++++++++++++++++++++++++++

>From [e-mail] (Kluev)
Date: Fri, 2 Sep 94 21:33:30 +0400
Organization: (none)

In article <33ire6$[e-mail]>
[e-mail] (RadixInc) wrote:

> I understand that the overhead of making the WNE toolbox call and
polling
> for events is time consuming, especially if you are trying to squeeze
the
> most performance out of a loop. Lots of programs just put up the
"watch"
> cursor and ignore all events while they do their computation. This is
> considered bad etiquette, because WNE does more than just feed events
to
> your app. It is the only way to let other processes have time.

EventAvail and GetNextEvent also allow other processes to work. Their
"time consuming" is approximately the same as of WaitNextEvent.

> Also keep in mind that, depending on the speed of the Mac you are
running
> on, events don't live all that long. The event queue only holds 20
events,
> and if you aren't removing them with WNE the old events will be lost.
That
> means you have to poll for events fast enough to catch them before
they
> are lost. User-interface events will happen much less frequently than
> every 10 ticks, but network events may happen very fast on certain
Macs.

Do you use those cool "network" events? This is not recommended
practice.

Michael Kluev.

+++++++++++++++++++++++++++

>From [e-mail] (RadixInc)
Date: 25 Aug 1994 01:11:10 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <[e-mail]>, [e-mail] (Ron
Nicholson) writes:

<<
A program has to call WaitNextEvent to cleanly check for a keyboard
abort (command-period).  I tried this in an inner loop of a compute
intensive application and it slowed down the computation noticeably.
I had to figure out a way to poll often enough to not make the user
interface seem sluggish, while slowing calculation down minimally.
>>

A program has to call WaitNextEvent to cleanly do a lot of things. If you
aren't checking events you are hogging the machine and not letting other
apps have time. And what do you mean "not make the user interface seem
sluggish?" What user interface do you have when you aren't checking for
events?

<<
First I install a VBL task whose only function is to increment a global
variable.  That gives me a tickcount variable that can be read without
a function call.  You can also use the TickCount() access function.
(Or you can just use the lowmem global Ticks at $016A if you aren't
strictly following Apple's guidelines.  Would I do that? :-)
>>

This is silly. Just call TickCount(), or if you have to, just look at
Ticks. You are overly worried about performance, yet you install a VBL
task that does the same thing as an existing VBL task (how do you think
Ticks gets updated in the first place?). You can use any DOCUMENTED
low-memory globals, like Ticks, without getting in trouble. Certainly
given the choice between that and installing a VBL, DTS would advise the
former.

As for the code sample, why not call EventAvail periodically with an event
mask that ignores events you don't care about? That way you won't end up
with an event loop inside your compute-intensive loop and (presumably)
another one in your main program. (DTS will certainly frown on calling
WaitNextEvent from more than one place in your program). And rather than
using Ticks and the local counter, use a modulo calculation on your loop
variable; e.g. check for an event every 10,000 iterations or so.

Make it work first, optimize the slow parts later [after identifying the
slow parts].

Gregory Jorgensen
Radix Consulting Inc.

---------------------------

>From dlopez@sailsun (Dean Lopez)
Subject: Standard C Libraries: use them?
Date: 12 Aug 1994 18:46:29 GMT
Organization: NASA Johnson Space Center, Houston, TX, USA

I am wondering about the 'legitimacy' of using the Standard C Libraries
in my Mac applications.  As a C programmer on other systems, I've become
quite fond of the Standard C libraries - stdio.h in particular.  The
problem with using them on the Mac, as I'm sure you all know, is the way
files are reference via FILE* 'ers compared with the File Manager's
file reference numbers.  If I use the File Manager, I don't see how I
can use the stdio.h functions which require a FILE*.  And if I use the
stdio.h functions, I can't use some of the File Manager's goodies.

Has anybody figured out how to convert the FILE structure info into the
FSSpec structure? (I mean written the routines already, I really don't
have the time right now to attempt it myself).
I'd just like to be able to interchange how I reference a file right
now, in the same way on say, a Data General system using AOS will let
me reference a file either with the stdio or Unix calls.

Is there a reason NOT to try to use either/or?

Any and all advice welcome. NOTE: if you e-mail me, see my email addresses
below, don't use what's in my reply-to field.  Its messed up somehow.
--
+---------------------------------------+-----------------------------+
| Dean Lopez                            |                             |
| SAIL DPS Engineer                     | [e-mail] |
| Rockwell Space Operations Co.         | [e-mail]           |
| JSC Shuttle Avionics Integration Lab  | [e-mail] |
+---------------------------------------+-----------------------------+
#include <standard_disclaimer.h>
/* The opinions expressed are all mine.
   RSOC doesn't speak for me and I don't speak for RSOC
   After all, I'm only an engineer - what do I know?     */

+++++++++++++++++++++++++++

>From [e-mail] (Keith Rollin)
Date: Thu, 18 Aug 1994 04:26:36 -0800
Organization: Apple ][ -> Mac -> Taligent -> Newton -> Windows?

In article <32gg25$[e-mail]>, dlopez@sailsun (Dean
Lopez) wrote:

>I am wondering about the 'legitimacy' of using the Standard C Libraries
>in my Mac applications.  As a C programmer on other systems, I've become
>quite fond of the Standard C libraries - stdio.h in particular.  The
>problem with using them on the Mac, as I'm sure you all know, is the way
>files are reference via FILE* 'ers compared with the File Manager's
>file reference numbers.  If I use the File Manager, I don't see how I
>can use the stdio.h functions which require a FILE*.  And if I use the
>stdio.h functions, I can't use some of the File Manager's goodies.
>
>Has anybody figured out how to convert the FILE structure info into the
>FSSpec structure? (I mean written the routines already, I really don't
>have the time right now to attempt it myself).
>I'd just like to be able to interchange how I reference a file right
>now, in the same way on say, a Data General system using AOS will let
>me reference a file either with the stdio or Unix calls.
>
>Is there a reason NOT to try to use either/or?

Check the Mac Technotes:

"Frequently, developers want to use both Macintosh file I/O and C file
I/O.  Developers who do this must keep in mind that they are combining two
distinct file representations (the Macintosh and ANSI C).  The only
limitation on mixing HFS and C I/O functions is that they cannot be mixed
on the same open file.  There are three reasons why this cannot be done.

"First, there is no routine that maps between a C FILE struct (returned by
fopen()) to an HFS fRefNum (needed to call HFS functions).  Similarly,
there is no call to create a FILE struct given an fRefNum returned by
FSOpen().  Thus, there is no way that the information from an fopen() call
could be used to do a FSRead().

"Second, even if the first problem were solved, the C libraries eventually
call the HFS file system, but keep some internal state information.  So,
if you call HFS directly (say, SetFPos()), the C file system has no way of
knowing a call was made and, therefore, doesnπt update its state
information.

"Similarly, there is no mechanism for synchronizing the C libraryπs
buffers.  For example, you perform an fwrite() with some number of
characters which get put into a buffer without flushing it.  Then you
perform an FSWrite() with something else.  Neither the C library nor HFS
are aware that the other has written to the file.

"Simply put, you cannot make HFS calls on a file opened with fopen() or
fdopen(); you cannot use C library I/O on a file opened under HFS."

- --------------------------------------------------------------------------
Keith Rollin --- Phantom Programmer --- Apple Computer, Inc. --- Team Newton

+++++++++++++++++++++++++++

>From [e-mail] (Jeremy Smith)
Date: 18 Aug 1994 15:37:49 GMT
Organization: Northwestern University, Evanston, IL  USA

   I'm not sure, what exactly you're trying to do, but if you have a copy
of Think Reference, go to misc. topics/Code Example Orphans/Printing a
Text File and look at the GotATextFile procedure.  This uses a medly of
toolbox and ANSI file routines.  Good luck,

   Jeremy Smith
   [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Phil Shapiro)
Date: Mon, 22 Aug 1994 14:37:27 -0400
Organization: Symantec Corp.

In article <[e-mail]>,
[e-mail] (Keith Rollin) wrote:

| In article <32gg25$[e-mail]>, dlopez@sailsun (Dean
| Lopez) wrote:
|
| >I am wondering about the 'legitimacy' of using the Standard C Libraries
| >in my Mac applications.  As a C programmer on other systems, I've become
| >quite fond of the Standard C libraries - stdio.h in particular.  The
| >problem with using them on the Mac, as I'm sure you all know, is the way
| >files are reference via FILE* 'ers compared with the File Manager's
| >file reference numbers.  If I use the File Manager, I don't see how I
| >can use the stdio.h functions which require a FILE*.  And if I use the
| >stdio.h functions, I can't use some of the File Manager's goodies.
| >
| >Is there a reason NOT to try to use either/or?
|
| Check the Mac Technotes:
|
| "First, there is no routine that maps between a C FILE struct (returned by
| fopen()) to an HFS fRefNum (needed to call HFS functions).  Similarly,
| there is no call to create a FILE struct given an fRefNum returned by
| FSOpen().  Thus, there is no way that the information from an fopen() call
| could be used to do a FSRead().

The Mac Technotes have always assumed that everyone is using the MPW
development system. If you're using THINK, you *can* get the refnum for an
open FILE. It's stored in the field called "refnum". You could also write
a stdio routine that builds a FILE* from an open file, since the THINK
libraries ship with full source. But that's a fair amount of work just
because you happen to like ANSI I/O. You will only be able to use the code
in THINK, too.

Unless you're porting a lot of code that already uses ANSI I/O, you're
much better off going with straight Mac I/O.

   -phil

+++++++++++++++++++++++++++

>From [e-mail] (John Nagle)
Date: Tue, 23 Aug 1994 02:02:25 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

[e-mail] (Phil Shapiro) writes:
>In article <[e-mail]>,
>[e-mail] (Keith Rollin) wrote:
>| In article <32gg25$[e-mail]>, dlopez@sailsun (Dean
>| Lopez) wrote:
>| >I am wondering about the 'legitimacy' of using the Standard C Libraries
>| >in my Mac applications.  As a C programmer on other systems, I've become
>| >quite fond of the Standard C libraries - stdio.h in particular.

>The Mac Technotes have always assumed that everyone is using the MPW
>development system. If you're using THINK, you *can* get the refnum for an
>open FILE.

>Unless you're porting a lot of code that already uses ANSI I/O, you're
>much better off going with straight Mac I/O.

        Of course, then you have to try to read a text file with the
Toolbox calls, a difficult, slow, and badly documented operation.
Anybody have the obscure tech note reference on doing that?

                    John Nagle

+++++++++++++++++++++++++++

>From [e-mail] (Zalman Stern)
Date: Tue, 23 Aug 1994 05:51:49 GMT
Organization: Adobe Systems Incorporated

That the Mac API prevents the use of stdio in many cases is just a bug. Any
reasonable UNIX system provides functions to map a FILE * to a file
descriptor (the moral equivalent of a Mac file reference number) and to open
a FILE * from a file descriptor. (They're called fileno and fdopen
respectively.) The conventions for switching between system call level I/O
and stdio are a bit arcane but workable for most uses of this functionality.
(The fdopen call is necessary because UNIX has a unified model of stream I/O
which a large number of things obey. There are many ways to get a file
descriptor, but once you have one it behaves according to this model and
turning it into a stdio stream is very useful.)

I've seen a number of posts recently that express the attitude that there is
no point in using portable API's for Macintosh programming because Mac
applications are inherently non-portable. (Or perhaps these posters feel a
program isn't a good Macintosh application unless its non-portable.) People
who feel this way are quickly becoming economic roadkill, and deservedly so.
One writes non-portable code because less than ideal circumstances forces
one to, not because it is desirable.
--
Zalman Stern           [e-mail]            [phone]
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
 Please do not change color while I am talking to you -- MC 900 Ft Jesus.

+++++++++++++++++++++++++++

>From [e-mail] (Tom Emerson)
Date: Tue, 23 Aug 1994 06:33:54 -0500
Organization: Symantec Development Tools Group

> >Unless you're porting a lot of code that already uses ANSI I/O, you're
> >much better off going with straight Mac I/O.
>
>         Of course, then you have to try to read a text file with the
> Toolbox calls, a difficult, slow, and badly documented operation.
> Anybody have the obscure tech note reference on doing that?

IM: Files, p. 2-90 & 2-122.

   -tre

--
Tom Emerson                                              Software Engineer
Development Tools Group                               Symantec Corporation
                          [e-mail]
  "I dreamed I had to take a test, in a Dairy Queen, on another planet."

+++++++++++++++++++++++++++

>From [e-mail] (Quinn "The Eskimo!")
Date: Thu, 25 Aug 1994 11:40:13 +0800
Organization: Department of Computer Science, The University of Western Australia

In article <[e-mail]>, [e-mail] (Zalman
Stern) wrote:

>That the Mac API prevents the use of stdio in many cases is just a bug.

I disagree with this.  Any API that promotes the use of full paths to
denote files is fundamentally broken for use on a Mac, mainly because
multiple volumes can have the same name.  Of course you can work around
this problem but there comes a point where you've got to decide whether
your workaround is worth the effort.
--
Quinn "The Eskimo!"        "Scout in a can. Simple, cheap, easy
                            to use and it's expendable!"

+++++++++++++++++++++++++++

>From [e-mail] (Zalman Stern)
Date: Thu, 25 Aug 1994 07:10:14 GMT
Organization: Adobe Systems Incorporated

Quinn "The Eskimo!" writes
> In article <[e-mail]>, [e-mail] (Zalman
> Stern) wrote:
> >That the Mac API prevents the use of stdio in many cases is just a bug.
>
> I disagree with this.  Any API that promotes the use of full paths to
> denote files is fundamentally broken for use on a Mac, mainly because
> multiple volumes can have the same name.  Of course you can work around
> this problem but there comes a point where you've got to decide whether
> your workaround is worth the effort.

Fine write a function like so:

    FILE * FSfopen(FSSpec *fileSpec, char *mode);

or perhaps a function that pops up a standard file dialog and opens a file
that way. Then you can write the file processing routines in a portable
fashion. The other alternative is to write your own stream library and
ensure that it is portable, but that is fraught with problems. (E.g. the
MacApp stream implementation which does no buffering.) I prefer not to
re-invent the wheel unless I have to.

My original point is that with a little work in the stdio implementation one
can go back and forth easily. My use of "The Mac API" is wrong. I meant the
standard C library implementation combined with the toolbox requirements.
Obviously the C library implementation is a better choice to change.
--
Zalman Stern           [e-mail]            [phone]
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
 Please do not change color while I am talking to you -- MC 900 Ft Jesus.

---------------------------

>From redial <[e-mail]>
Subject: Summary of 'Safe Save' problem - IM:Files flawed!
Date: Thu, 25 Aug 1994 04:29:12 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

Netters -

Awhile ago I posted a request for help with a problem I was having
implementing the 'Safe Save' routine outlined in Inside Macintosh:Files, pp.
1-25,26.  A 'safe save' is a save routine which creates a temporary file on
disk, saves the data to it, and - if no error occurs - swaps the the
directory information for the two files, and then deletes the temporary file.
 The advantage over a 'direct save' to the existing file is that if an error
were to occur, the existing file could be damaged and its data erased or
corrupted.  The IM example code is in Pascal (naturally), but since I am
working in C I attempted to translate it to that language.  The problem I ran
into was that after the directory swap between the files, I would get a 'file
busy' error when I attempted to delete the temporary file.  This was quite
puzzling since the code clearly executes a command to close the temporary
file immediately before the delete command.

Scott Bronson pointed out that the swap command, FSpExchangeFiles, swaps
the FCBs too, and recommended closing both files before swapping.  However, a
comment line in the original pascal example directed that the data fork of
the existing file be opened and left open!  I wondered why, but Scott thought
this was just another example of how inaccurate the code examples in IM can
be.  The bugginess of the 'Safe Save' routine certainly attests to this fact!

Further snooping led to several bits of info about the two files which
enabled Troy Gaul to correctly diagnose that the IM example code called for a
resource to be written to the original file BEFORE the swap.  Thus, it
contained the resource and the old data, while the temporary file contained
only the new data.  AFTER the swap, the original file then contained only the
new data while the temporary file contained the resource and the old data.
Troy also pointed out that since FSpExchangeFiles also swaps the FCBs if
either or both files are open, the FSClose routine needs to use the path
reference number of the _original_ file in order to actually close the
temporary file!  This means that future references to the original file will
require the use of the temporary file's path refnum, so it must be saved.

Yet another error was discovered by Jens-Uwe Mager.  The IM:Files example
used the FSClose routine to close the resource fork of the original file, but
this did not cause the resource data to actually be flushed to the disk.  He
correctly suggested the use of CloseResFile, which (contrary to my initial
response to him) does work exactly like it should.

The first part of the fix is to move the resource creating code from the
DoSaveAsCmd routine to the DoWriteFile routine.  However, you must continue
to allow the DoSaveAsCmd routine to open the original file's data fork and
leave it open.  This is important because of the interplay between the 'Save'
and the 'Save As...' file menu commands.  The first time the user saves his
file, the DoSaveAsCmd routine is going to be executed regardless of which
command was chosen.  Thereafter, each time the user selects the 'Save'
command, the DoSaveAsCmd routine is bypassed and flow goes directly to
DoWriteData.  You could allow DoWriteData to open the original file's data
fork, but then you'd also have to close it again before leaving the routine.
Putting just one call to open the data fork in the DoSaveAsCmd is more
efficient.

The second part of the fix is to make the DoWriteFile routine create the
temporary file, copy the resource to its resource fork, and close the
resource fork with CloseResFile.  Then the routine should open the temp
file's data fork, write the current data to it, and leave it open also.  Do
the swap using FSpExchangeFiles. NOW the path reference numbers of the two
files, which locate their data in memory, are reversed, but their FSSpecs are
not.  Close the temp file by calling FSClose with the _original_ file's path
reference number.  Save the _temporary_ file's path reference number for
future use with the file, and then delete the temp file by calling FSpDelete
with the temporary file's FSSpec.

Sorry to be so long winded.  If anyone wishes to see the final code, drop me
an email.  And sincere thanks to all who helped.

 ===============================================================
|  Ron Goebel                  |                                |
|  G & V Systems               | Whatdya mean 'I don't get it?' |
|  Internet: [e-mail] |                                |
 ===============================================================

---------------------------

>From [e-mail] (Dan Eldridge)
Subject: What Happens in the Resource Fork
Date: 18 Aug 1994 14:23:26 GMT
Organization: Redcon

Hi

Here's A general question, that I'm sure someone can answer,
What happens in the Resource Fork if a program significantly and often
changes the size of one of the resources, does the fork get fragmented, or
does the whole file get rewritten so that the forks are all contiguous?



Just Wondering

--
  Dan
Redcon

***
insert favorite corn dog joke here
***

+++++++++++++++++++++++++++

>From mclow@san_marcos.csusm.edu (Marshall Clow)
Date: Thu, 18 Aug 1994 09:26:20 -0800
Organization: Aladdin Systems

In article <[e-mail]>,
[e-mail] (Dan Eldridge) wrote:

> Hi
>
> Here's A general question, that I'm sure someone can answer,
> What happens in the Resource Fork if a program significantly and often
> changes the size of one of the resources, does the fork get fragmented, or
> does the whole file get rewritten so that the forks are all contiguous?
>
   My experience has been that if you make resources smaller (or possibly
delete them), the extra space in the file is left unused, but if you add a
resource or make one larger, then it is added at the end and the file is
compacted in UpdateResFile. (which is called from CloseResFile)

-- Marshall

--
Marshall Clow
Aladdin Systems
mclow@san_marcos.csusm.edu

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Wed, 24 Aug 1994 17:53:54 GMT
Organization: Apple Computer

Dan Eldridge, [e-mail] writes:
> What happens in the Resource Fork if a program significantly and often
> changes the size of one of the resources, does the fork get fragmented, or
> does the whole file get rewritten so that the forks are all contiguous?

When you call UpdateResFile or CloseResFile, all the data gets shuffled
around on disk until it's contiguous. Needless to say this can be very slow.
Remember those long delays you sometimes get when you close the Monitors
control panel or use some utility to update the desktop pattern? That's the
cause; the System file is rather large, esp. pre-7.1 systems that had all the
fonts in the System file itself. And the best part is, if you decide your
system's hung and reboot, you've just destroyed your system file! That's the
major reason we made Wallpaper not store its desktop pattern in the System
file.

All the more reason why (let's all chant it together) "The Resource Manager
is not a database!"

--Jens Alfke                           [e-mail]
                   "A man, a plan, a yam, a can of Spam ... Bananama!"

+++++++++++++++++++++++++++

>From [e-mail] (Kluev)
Date: Thu, 25 Aug 94 20:58:39 +0400
Organization: (none)

In article <[e-mail]>
Jens Alfke <[e-mail]> wrote:

> Dan Eldridge, [e-mail] writes:
> > What happens in the Resource Fork if a program significantly and
often
> > changes the size of one of the resources, does the fork get
fragmented, or
> > does the whole file get rewritten so that the forks are all
contiguous?
>
> When you call UpdateResFile or CloseResFile, all the data gets
shuffled
> around on disk until it's contiguous. Needless to say this can be
very slow.

This data compacting occurred in "logical" space of fork instead of
"physical". Compacting removes empty space in fork (not on disk)
created when a resource was removed, made smaller, or larger.
"Physically", file can be shuffled around all the disk.
So the answer is: Yes, the fork get fragmented.

Michael Kluev.

---------------------------

>From [e-mail] (Doug Schwarz)
Subject: Why does NewGWorld do this?
Date: Tue, 23 Aug 1994 20:07:42 GMT
Organization: Eastman Kodak Company, Rochester, NY

I am trying to create multiple offscreen graphics worlds.

    QDErr           err1, err2;
    PixMapHandle    pixBase1, pixBase2;
    GWorldPtr       theGWorld1, theGWorld2;
    CGrafPtr        currentPort;
    GDHandle        currentDevice;
    Rect            boundsRect;

    GetGWorld(¤tPort, ¤tDevice);
    err1 = NewGWorld(&theGWorld1, 32, &boundsRect, NULL, NULL, 0);
    pixBase1 = GetGWorldPixMap(theGWorld1);
    SetGWorld(currentPort, currentDevice);

    GetGWorld(¤tPort, ¤tDevice);
    err2 = NewGWorld(&theGWorld2, 32, &boundsRect, NULL, NULL, 0);
    pixBase2 = GetGWorldPixMap(theGWorld2);
    SetGWorld(currentPort, currentDevice);


In the code fragment above, theGWorld1 gets allocated just fine (and pixBase1
looks ok), but theGWorld2 is NULL (and pixBase2 is not valid).  Both err1
and err2 are zero.  What is going on/what am I doing wrong?  There is no
mention in IM VI what a zero GWorldPtr means.  I had assumed that it would
mean that there wasn't enough memory to allocate the pixel maps, but the pixel
maps aren't very large and I have the memory partition for the app set plenty
large.  Thanks for any help you can give me.

Doug Schwarz
Eastman Kodak Company
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Steven J. Bushell)
Date: Wed, 24 Aug 1994 11:48:59 -0500
Organization: Kodak Electronic Printing Systems, Inc.

In article <schwarz-2308941607420001@150.220.61.78>, [e-mail]
(Doug Schwarz) wrote:
[ code deleted ]
> In the code fragment above, theGWorld1 gets allocated just fine (and pixBase1
> looks ok), but theGWorld2 is NULL (and pixBase2 is not valid).  Both err1
> and err2 are zero.  What is going on/what am I doing wrong?  There is no
> mention in IM VI what a zero GWorldPtr means.  I had assumed that it would
> mean that there wasn't enough memory to allocate the pixel maps, but the pixel
> maps aren't very large and I have the memory partition for the app set plenty
> large.  Thanks for any help you can give me.
>
> Doug Schwarz
> Eastman Kodak Company
> [e-mail]

It's an undocumented feature of NewGWorld that it returns no error when it
has insufficient memory to allocate the GWorld.  You should ALWAYS check
the GWorldPtr to determine if the call was successful.  The only time you
get errors back from NewGWorld is when you pass ridiculous parameters to
it.  I've never seen any other errors come back from it.

Considering this, plus the fact that the first call to NewGWorld was
successful, you can pretty safely assume that you are short on memory.
Double-check your boundsRect, and make sure your heap isn't fragmented
too.  A quick way to confirm that it is a memory problem would be to cut
the boundsRect in half and see if both calls succeed.  If they don't,
check to make sure your heap's okay.

- Steve

//////////
//
//   Steve Bushell
//   [e-mail]
//
//   "It's always the quiet ones."
//
//////////

+++++++++++++++++++++++++++

>From [e-mail] (Dana Basken)
Date: 24 Aug 1994 16:41:23 GMT
Organization: Rockland Software

In article <python-2408941148590001@155.50.26.175>
[e-mail] (Steven J. Bushell) writes:

> It's an undocumented feature of NewGWorld that it returns no error when it
> has insufficient memory to allocate the GWorld.  You should ALWAYS check
> the GWorldPtr to determine if the call was successful.  The only time you
> get errors back from NewGWorld is when you pass ridiculous parameters to
> it.  I've never seen any other errors come back from it.

It's odd that you have never seen any other errors return from
NewGWorld.  If and when I try to create a GWorld using NewGWorld that
is too large to fit into memory, I get a result code of -108
(memFullErr) every time.  In my experience, I've never seen NewGWorld
not create a GWorld and pass back noErr.

I would look for some other reason in the failure of the allocation of
your GWorld.

- Dana

- -
Dana Basken              [e-mail]
Rockland Software

+++++++++++++++++++++++++++

>From [e-mail] (Thurman Gillespy III)
Date: Wed, 24 Aug 1994 11:55:51 -0800
Organization: Dept of Radiology, Univ of Washington

In article <schwarz-2308941607420001@150.220.61.78>, [e-mail]
(Doug Schwarz) wrote:

> I am trying to create multiple offscreen graphics worlds.
>
>     QDErr           err1, err2;
>     PixMapHandle    pixBase1, pixBase2;
>     GWorldPtr       theGWorld1, theGWorld2;
>     CGrafPtr        currentPort;
>     GDHandle        currentDevice;
>     Rect            boundsRect;
>
>     GetGWorld(¤tPort, ¤tDevice);
>     err1 = NewGWorld(&theGWorld1, 32, &boundsRect, NULL, NULL, 0);
>     pixBase1 = GetGWorldPixMap(theGWorld1);
>     SetGWorld(currentPort, currentDevice);
>
>     GetGWorld(¤tPort, ¤tDevice);
>     err2 = NewGWorld(&theGWorld2, 32, &boundsRect, NULL, NULL, 0);
>     pixBase2 = GetGWorldPixMap(theGWorld2);
>     SetGWorld(currentPort, currentDevice);
>
Err, you HAVE defined boundsRect further, havn't you?
--
Thurman Gillespy III             |  [e-mail]
Department of Radiology, SB-05   |  voice [phone]
University of Washington         |  fax   [phone]
Seattle, WA 98195                |

+++++++++++++++++++++++++++

>From [e-mail] (Daniel Craig Jalkut)
Date: 24 Aug 1994 21:21:31 GMT
Organization: University of California, Santa Cruz


In <schwarz-2308941607420001@150.220.61.78> [e-mail] (Doug Schwarz) writes:

>I am trying to create multiple offscreen graphics worlds.

>    QDErr           err1, err2;
>    PixMapHandle    pixBase1, pixBase2;
>    GWorldPtr       theGWorld1, theGWorld2;
>    CGrafPtr        currentPort;
>    GDHandle        currentDevice;
>    Rect            boundsRect;

>    GetGWorld(¤tPort, ¤tDevice);
>    err1 = NewGWorld(&theGWorld1, 32, &boundsRect, NULL, NULL, 0);
>    pixBase1 = GetGWorldPixMap(theGWorld1);
>    SetGWorld(currentPort, currentDevice);

>    GetGWorld(¤tPort, ¤tDevice);
>    err2 = NewGWorld(&theGWorld2, 32, &boundsRect, NULL, NULL, 0);
>    pixBase2 = GetGWorldPixMap(theGWorld2);
>    SetGWorld(currentPort, currentDevice);


>In the code fragment above, theGWorld1 gets allocated just fine (and pixBase1
>looks ok), but theGWorld2 is NULL (and pixBase2 is not valid).  Both err1
>and err2 are zero.  What is going on/what am I doing wrong?  There is no
>mention in IM VI what a zero GWorldPtr means.  I had assumed that it would
>mean that there wasn't enough memory to allocate the pixel maps, but the pixel
>maps aren't very large and I have the memory partition for the app set plenty
>large.  Thanks for any help you can give me.

>Doug Schwarz
>Eastman Kodak Company
>[e-mail]

Any GWorld references I've read have always insisted that you check
both the return value being noErr, *and* the GworldPtr being != NULL.
Probably you are somehow passing NewGWorld parameters that seem ok,
and it does it's job ok, but doesn't put the results where you expect
it to. I can't see from your example code anything that looks wrong in
the NewGWorld calls.  It is weird that you call GetGWorld and SetGWorld
before and after your NewGWorld calls, though.  I may be wrong, but  I
don't think NewGWorld does any modification to the active GrafPort or
GDevice.  You only need to Get/SaveGworld before and after you do
any drawing to the GWorld(just like a GrafPort, in fact I've seen it
recommended that if you use GWorlds at all your just use Get/SaveGWorld
in *lieu* of Get/SavePort.

The main problem I ran into when learning GWorlds was running out of memory,
and it did return the proper error code.  I concur with the other person
who said that they have never had NewGWorld return noErr in  reaction
to an out of memory error.  If you use GWorlds or anything else that is
memory intensive, you will probably have to change the default heap size
of your application from whatever compiler you use.

--
 ____
/ /\ \    Daniel Craig Jalkut       "All I know is that I don't know nothing,
-/--\-  [e-mail]    and that's FINE" -- Operation Ivy
X____X  UNIX, coffee, politics, punk-rock, Mac, women, food, and more.


+++++++++++++++++++++++++++

>From Darrin Cardani <[e-mail]>
Date: Wed, 24 Aug 1994 19:34:38 GMT
Organization: AT&T Global Information Solutions, Atlanta

>In article <33ft7j$[e-mail]> Dana Basken writes:
>In article <python-2408941148590001@155.50.26.175>
>[e-mail] (Steven J. Bushell) writes:
>
>> It's an undocumented feature of NewGWorld that it returns no error when it
>> has insufficient memory to allocate the GWorld.  You should ALWAYS check
>> the GWorldPtr to determine if the call was successful.  The only time you
>> get errors back from NewGWorld is when you pass ridiculous parameters to
>> it.  I've never seen any other errors come back from it.
>
>It's odd that you have never seen any other errors return from
>NewGWorld.  If and when I try to create a GWorld using NewGWorld that
>is too large to fit into memory, I get a result code of -108
>(memFullErr) every time.  In my experience, I've never seen NewGWorld
>not create a GWorld and pass back noErr.

I too have seen the noErr, but no memory problem. Is there maybe more to
it than those 2 factors? (Maybe, there's enough mem., but it's too fragmented
or something wacko like that?)

Darrin







+++++++++++++++++++++++++++

>From [e-mail] (Doug Schwarz)
Date: Wed, 24 Aug 1994 20:26:47 GMT
Organization: Eastman Kodak Company, Rochester, NY

In article <33ft7j$[e-mail]>, [e-mail] (Dana Basken) wrote:

> It's odd that you have never seen any other errors return from
> NewGWorld.  If and when I try to create a GWorld using NewGWorld that
> is too large to fit into memory, I get a result code of -108
> (memFullErr) every time.  In my experience, I've never seen NewGWorld
> not create a GWorld and pass back noErr.
>
> I would look for some other reason in the failure of the allocation of
> your GWorld.
>
> - Dana

I wrote a small application containing little more than my original code
fragment and I also get a result of -108 when there is not enough memory.
It never returns a null GWorld and a zero error.  So, it seems that I need
to give a more complete description of my original problem.

I am using THINK C 7.0.3 and the TCL 1.1.3.  The allocation of the GWorlds
is done in the initialization method for a class.  I create two instances
of my class and initialize them like so:

    SetRect(&bounds, ...);
    instance1 = new(COffscreenPixMap);
    instance1->IOffscreenPixMap(bounds);
    instance2 = new(COffscreenPixMap);
    instance2->IOffscreenPixMap(bounds);

where, IOffscreenPixMap() is something like:


class COffscreenPixMap : CObject
{
private:
    CGrafPtr    currentPort;
    GDHandle    currentDevice;
    GWorldPtr   theGWorld;

public:
    void        IOffscreenPixMap(Rect);
};

void COffscreenPixMap::IOffscreenPixMap(Rect boundsRect)
{
    QDErr           err, qderr;
    PixMapHandle    pixBase;

    GetGWorld(¤tPort, ¤tDevice);
    err = NewGWorld(&theGWorld, 32, &boundsRect, NULL, NULL, 0);
    qderr = QDError();
    pixBase = GetGWorldPixMap(theGWorld);
    SetGWorld(currentPort, currentDevice);
    return;
}


When I step through the program using the source level debugger,
everything works fine with instance1.  When I get to NewGWorld for
instance2, I get
err = 0, theGWorld = NULL and qderr = 0.  If I purposely set the memory
partition for the app too low, I never return from NewGWorld, but I get a
dialog from the TCL telling me that there is not enough memory.  (This I
also do not understand).  The app never really recovers from this and I
have to enter MacsBug and do an ES.  I don't really care about that right
now, I just want to be able to allocate my second GWorld.

Please note: I definitely have enough memory to allocate these two
GWorlds.  They each take a little over 1 MB and I have the memory
partition for the app set to 23 MB (the machine has 32M).  All of this
stuff is right at the beginning of IApplication() so no other large
objects have been created.

Thanks for all the help so far!  Does anybody know what is going on?

Doug Schwarz
Eastman Kodak Company
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Brian Stern)
Date: 25 Aug 1994 05:25:14 GMT
Organization: The University of Texas at Austin, Austin, Texas

In article <schwarz-2408941626470001@150.220.61.78>, [e-mail]
(Doug Schwarz) wrote:

> I wrote a small application containing little more than my original code
> fragment and I also get a result of -108 when there is not enough memory.
> It never returns a null GWorld and a zero error.  So, it seems that I need
> to give a more complete description of my original problem.
>
> When I step through the program using the source level debugger,
> everything works fine with instance1.  When I get to NewGWorld for
> instance2, I get
> err = 0, theGWorld = NULL and qderr = 0.  If I purposely set the memory
> partition for the app too low, I never return from NewGWorld, but I get a
> dialog from the TCL telling me that there is not enough memory.  (This I
> also do not understand).  The app never really recovers from this and I
> have to enter MacsBug and do an ES.  I don't really care about that right
> now, I just want to be able to allocate my second GWorld.
>
> Please note: I definitely have enough memory to allocate these two
> GWorlds.  They each take a little over 1 MB and I have the memory
> partition for the app set to 23 MB (the machine has 32M).  All of this
> stuff is right at the beginning of IApplication() so no other large
> objects have been created.
>
> Thanks for all the help so far!  Does anybody know what is going on?
>
> Doug Schwarz
> Eastman Kodak Company
> [e-mail]

Hi Doug,

Guess what.  You are successfully creating two GWorlds.  That's why your
return values are err = 0, and qderr = 0.  The problem is that the
GWorldPtr isn't going where you think it is.  In TCL 1.1.3 objects are
handles and your instance variables can move when you call a toolbox
routine that can move memory, like NewGWorld.  You have two choices.  Use
local variables when you need to pass by reference and copy the result to
your instance variables or else lock the object using the utility routine
'Lock'.

The problem you mention with the TCL not enough mem error msg is because
TCL has a GrowZone proc.  If it can't free up enough mem to satisfy the
request it throws an exception.  This includes a longjump out of the trap
that was requesting memory.  I think that this can screw up everything, as
you discovered.

--
Brian  Stern  :-{)}
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Steven J. Bushell)
Date: Thu, 25 Aug 1994 11:44:02 -0500
Organization: Kodak Electronic Printing Systems, Inc.

In article <schwarz-2408941626470001@150.220.61.78>, [e-mail]
(Doug Schwarz) wrote:

> void COffscreenPixMap::IOffscreenPixMap(Rect boundsRect)
> {
>     QDErr           err, qderr;
>     PixMapHandle    pixBase;
>
>     GetGWorld(¤tPort, ¤tDevice);
>     err = NewGWorld(&theGWorld, 32, &boundsRect, NULL, NULL, 0);
>     qderr = QDError();
>     pixBase = GetGWorldPixMap(theGWorld);
>     SetGWorld(currentPort, currentDevice);
>     return;
> }
> Thanks for all the help so far!  Does anybody know what is going on?

Have you tried locking your object before creating the GWorld?  If you
don't, the address of 'theGWorld' can become invalid if memory moves
around (i.e., when creating a new GWorld), and the pointer to the GWorld
will be stored in some random place in memory.  Remember, TCL 1.1.3 is
still handle-based so you have to watch out when using addresses of
instance vars; TCL 2.0 is pointer based so you can avoid these problems if
you use a newer TCL.

- Steve

//////////
//
//   Steve Bushell
//   [e-mail]
//
//   "It's always the quiet ones."
//
//////////

+++++++++++++++++++++++++++

>From [e-mail] (Doug Schwarz)
Date: Thu, 25 Aug 1994 17:26:03 GMT
Organization: Eastman Kodak Company, Rochester, NY

In article <[e-mail]>,
[e-mail] (Brian Stern) wrote:

> Guess what.  You are successfully creating two GWorlds.  That's why your
> return values are err = 0, and qderr = 0.  The problem is that the
> GWorldPtr isn't going where you think it is.  In TCL 1.1.3 objects are
> handles and your instance variables can move when you call a toolbox
> routine that can move memory, like NewGWorld.  You have two choices.  Use
> local variables when you need to pass by reference and copy the result to
> your instance variables or else lock the object using the utility routine
> 'Lock'.
>
> The problem you mention with the TCL not enough mem error msg is because
> TCL has a GrowZone proc.  If it can't free up enough mem to satisfy the
> request it throws an exception.  This includes a longjump out of the trap
> that was requesting memory.  I think that this can screw up everything, as
> you discovered.
>
> --
> Brian  Stern  :-{)}
> [e-mail]


In article <python-2508941144020001@155.50.26.175>, [e-mail]
(Steven J. Bushell) wrote:

> Have you tried locking your object before creating the GWorld?  If you
> don't, the address of 'theGWorld' can become invalid if memory moves
> around (i.e., when creating a new GWorld), and the pointer to the GWorld
> will be stored in some random place in memory.  Remember, TCL 1.1.3 is
> still handle-based so you have to watch out when using addresses of
> instance vars; TCL 2.0 is pointer based so you can avoid these problems if
> you use a newer TCL.
>
> - Steve
>
> //   Steve Bushell
> //   [e-mail]



Yes!  Brian and Steve are correct.  I replaced

    err = NewGWorld(&theGWorld, 32, &boundsRect, NULL, NULL, 0);

where theGWorld is an instance variable, with

    GWorldPtr    tempGWorld;
    err = NewGWorld(&tempGWorld, 32, &boundsRect, NULL, NULL, 0);
    theGWorld = tempGWorld;

where tempGWorld is a local variable and it works just fine.  I was also able to
make some other simplifications once *that* was working (thanks to some other
helpful suggestions).

So, THANK YOU EVERYBODY and especially Brian and Steve!

Doug Schwarz
Eastman Kodak Company
[e-mail]

---------------------------

>From [e-mail] (Vincent Partington)
Subject: Won't strange windows come in my layer?
Date: 23 Aug 1994 11:09:43 GMT
Organization: FWI, University of Amsterdam

Hi everyone,

I'm investigating putting a pointer to an object in the refCon of a windowPtr
to call a virtual function (C++) through it. I was wondering:
Can I be sure I'll only get events for my own windows? Can I be sure the
refCon value doesn't contain garbage?
I know under System 6 DA's would invade your window list but they can be
recognized by looking at the windowKind (or something). It's it ok for my
app to break if somebody makes an INIT that puts windows in my layer?

Thanks, Vincent
--
appel peer banaan baksteen           ||| The Fingerware Project:
schelp zon zand rolstoel             ||| Put your code snippets in your .plan!
groen wit geel flatgebouw            ||| If you want to know more
boer postbode bouwvakker roos        ||| finger [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Brian Stern)
Date: 23 Aug 1994 16:44:50 GMT
Organization: The University of Texas at Austin, Austin, Texas

In article <33cldn$[e-mail]>, [e-mail] (Vincent
Partington) wrote:

> Hi everyone,
>
> I'm investigating putting a pointer to an object in the refCon of a windowPtr
> to call a virtual function (C++) through it. I was wondering:
> Can I be sure I'll only get events for my own windows? Can I be sure the
> refCon value doesn't contain garbage?
> I know under System 6 DA's would invade your window list but they can be
> recognized by looking at the windowKind (or something). It's it ok for my
> app to break if somebody makes an INIT that puts windows in my layer?
>
> Thanks, Vincent
> --
> appel peer banaan baksteen           ||| The Fingerware Project:
> schelp zon zand rolstoel             ||| Put your code snippets in your .plan!
> groen wit geel flatgebouw            ||| If you want to know more
> boer postbode bouwvakker roos        ||| finger [e-mail]

Vincent,

You should set the WindowKind of any window when you create it; choose
values that are not among the already defined values (> 8 I think).  Then
when you receive window events you check the windowkind first and then act
accordingly.  You can put anything you like in the refcon, including
object references.  If you do this then presumably you wouldn't do
anything for a windowkind that your app doesn't know about.

I wouldn't worry about an INIT putting windows in your layer.  If I was
writing an INIT to do such a thing I'd be sure to steal any window events
related to that window before your app ever saw them.

--
Brian  Stern  :-{)}
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Jonas Wallden)
Date: 23 Aug 1994 21:02:05 GMT
Organization: (none)

[e-mail] (Brian Stern) writes:

>In article <33cldn$[e-mail]>, [e-mail] (Vincent
>Partington) wrote:

>> Hi everyone,
>>
>> I'm investigating putting a pointer to an object in the refCon of a windowPtr
>> to call a virtual function (C++) through it. I was wondering:
>> Can I be sure I'll only get events for my own windows? Can I be sure the
>> refCon value doesn't contain garbage?
>> I know under System 6 DA's would invade your window list but they can be
>> recognized by looking at the windowKind (or something). It's it ok for my
>> app to break if somebody makes an INIT that puts windows in my layer?
>>
>> Thanks, Vincent
>> --
>> appel peer banaan baksteen         ||| The Fingerware Project:
>> schelp zon zand rolstoel           ||| Put your code snippets in your .plan!
>> groen wit geel flatgebouw          ||| If you want to know more
>> boer postbode bouwvakker roos      ||| finger [e-mail]
>
>Vincent,
>
>You should set the WindowKind of any window when you create it; choose
>values that are not among the already defined values (> 8 I think).  Then
>when you receive window events you check the windowkind first and then act
>accordingly.  You can put anything you like in the refcon, including
>object references.  If you do this then presumably you wouldn't do
>anything for a windowkind that your app doesn't know about.
>
>I wouldn't worry about an INIT putting windows in your layer.  If I was
>writing an INIT to do such a thing I'd be sure to steal any window events
>related to that window before your app ever saw them.
>
>Brian  Stern  :-{)}

A great way to extend WindowRecords is to declare your own data type with
a WindowRecord as the first item.

E.g.,

struct tMyWinData {
   //  This must come first!
   WindowRecord   winRec;

   //  Additional window-specific data here...
   Handle         aHandle;
   Ptr            aPtr;
};
typedef struct tMyWinData tMyWinData;
typedef tMyWinData *tMyWinPtr;

The trick now is that you can typecast any window pointer to tMyWinPtr (and
back) and access your window-specific data fields. You might want to place
your application's unique creator code in the WindowRecord refCon field and
check it first to be sure you have a window that belongs to your program.

I use this all the time and it is useful in many other places where the
system gives you a pointer to an object (VBL tasks, ParamBlocks, ...) and
you need to store extra data. No need to use any globals for this stuff!

--
`.`.   Jonas Wallden                    `.`.`.`.`.`.`.`.`.`.`.`.`.`.`.`.`.
`.`.`.   Internet: [e-mail]  `.`.`.`.`.`.`.`.`.`.`.`.`.`.`.`.
`.`.`.`.   AppleLink: sw1369                `.`.`.`.`.`.`.`.`.`.`.`.`.`.`.

+++++++++++++++++++++++++++

>From [e-mail] (Benjamin Herrenschmidt)
Date: Tue, 23 Aug 94 17:24:09 +0100
Organization: (none)


In article <33cldn$[e-mail]> (comp.sys.mac.programmer), [e-mail] (Vincent Partington) writes:

>I'm investigating putting a pointer to an object in the refCon of a windowPtr
>to call a virtual function (C++) through it. I was wondering:
>Can I be sure I'll only get events for my own windows? Can I be sure the
>refCon value doesn't contain garbage?
>I know under System 6 DA's would invade your window list but they can be
>recognized by looking at the windowKind (or something). It's it ok for my
>app to break if somebody makes an INIT that puts windows in my layer?

I think you should have somewhere a list of YOUR windows, so you can
check it's one of yours before using it's refcon. Another way to do
so is to use a custom windowKind and check for it (that's what PowerPlant
does) but you are not protected against someone using the same windowKind
(there is no way to register them).

BenH.

+++++++++++++++++++++++++++

>From [e-mail] (Larry Rosenstein)
Date: Tue, 23 Aug 1994 23:04:25 GMT
Organization: Taligent, Inc.

In article <33cldn$[e-mail]>, [e-mail] (Vincent
Partington) wrote:

> Can I be sure I'll only get events for my own windows? Can I be sure the
> refCon value doesn't contain garbage?

No.  For example, there's a program called PacerForum (a BBS app) that can
pop up notification windows inside your application's space.  It makes the
windows look like DAs (negative windowKind) so if you handle those
properly you should be OK.

--
Larry Rosenstein
Taligent, Inc.

[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Jon W{tte)
Date: Wed, 24 Aug 1994 10:23:51 +0200
Organization: Royal Institute of Something or other

In article <33cldn$[e-mail]>,
[e-mail] (Vincent Partington) wrote:

>It's it ok for my
>app to break if somebody makes an INIT that puts windows in my layer?

Yes; PowerPlant, TCL and MacApp all put object pointers in the
refCon. To be really safe, set the windowKind of windows you
create to something >8, like 11147, and test for that first.
Also test that the object pointer is not 0 (and if you're
paranoid; not odd and above your heap start and below your
stack base)

Cheers,

                / h+


--
  Jon W‰tte ([e-mail]), Hagagatan 1, 113 48 Stockholm, Sweden
 "Don't use the Layer Manager"


+++++++++++++++++++++++++++

>From [e-mail] (Jon W{tte)
Date: Wed, 24 Aug 1994 23:10:45 +0200
Organization: Royal Institute of Something or other

In article <[e-mail]>,
[e-mail] (Benjamin Herrenschmidt) wrote:

>I think you should have somewhere a list of YOUR windows, so you can
>check it's one of yours before using it's refcon. Another way to do
>so is to use a custom windowKind and check for it (that's what PowerPlant
>does) but you are not protected against someone using the same windowKind
>(there is no way to register them).

No, but there is simply NO WAY that someone elses window gets
into your window list, unless that's a DA/system window, in
which case the windowKind will be negative. Using a separate
list is just a lot of trouble to avoid something which won't
happen; sort of lugging around a portable bomb shelter in case
a meteorite would hit you...

Cheers,


                / h+


--
  Jon W‰tte ([e-mail]), Hagagatan 1, 113 48 Stockholm, Sweden
 "Don't use the Layer Manager"


+++++++++++++++++++++++++++

>From [e-mail] (Sigurdur Asgeirsson)
Date: 25 Aug 1994 09:03:27 GMT
Organization: Plusplus Inc.

[e-mail] (Jon W{tte) writes:

>In article <[e-mail]>,
>[e-mail] (Benjamin Herrenschmidt) wrote:

>>I think you should have somewhere a list of YOUR windows, so you can

[snip]

>No, but there is simply NO WAY that someone elses window gets
>into your window list, unless that's a DA/system window, in
>which case the windowKind will be negative. Using a separate
>list is just a lot of trouble to avoid something which won't
>happen; sort of lugging around a portable bomb shelter in case
>a meteorite would hit you...

  Uhm, hate to rain on your parade, but what about CTB windows? CTB
tools are allowed to put up windows (just about anytime if I remember
correctly), AND they use the RefCon for their own purposes, so if
you're using the CTB beware...

--
Sigurdur Asgeirsson    | "Well you know, C isn't that hard, void (*(*f[])())()
Kambasel 26            | for instance declares f as an array of unspecified
109 Reykjavik, Iceland | size, of pointers to functions that return pointers to
[e-mail]   | functions that return void... I think"

---------------------------

End of C.S.M.P. Digest
**********************